In maintaining and controlling access to data, a pivotal concern is data integrity. In networked systems, many users and applications may concurrently seek to access the same data. Even in a standalone system, multiple applications may concurrently attempt to read data from or write data to the same address, possibly with multiple processing threads of multiple applications representing clients that contend with one other to access data. Because it is difficult to foresee, let alone avoid, the myriad situations in which multiple clients may seek conflicting access to data, it is important to control access to the data to ensure that one client does not contemporaneously overwrite data on which another client currently relies.
One way to preserve data integrity is to place a lock on selected data. When the selected data is locked for exclusive access, other clients may not read or overwrite the selected data until a client having the lock releases the data to other clients. The client having the lock can rely on the selected data not being changed by other clients until the client releases the lock. Similarly, because other clients cannot access the selected data until the lock is removed, the lock prevents the other clients from performing operations based on outdated values of the selected data.
One form of lock is a lease. A lease places a lock on selected data until a specified expiration time is reached. The specified expiration time ensures that the selected data will not be locked indefinitely even if contact with a client is lost, as a result of a software, network, or hardware failure, or if the client merely fail to return the lease.
For example, a read lease provides selected data to a client with the assurance that the value of the selected data will not change until the client returns the lease or the expiration time is reached. Other clients may be provided with concurrent read leases to the selected data, and these other read leases may specify a later or earlier expiration time. Concurrent read leases do not conflict with one another because the operation of reading data is commutative: The order in which concurrent reads are executed has no effect on the result of the read operations. If subsequently issued read leases specify a later expiration time, they only serve to extend the time through which the values of the selected data will not change. Correspondingly, a write lease allows a client to overwrite the selected data up to the specified expiration time. Write leases conflict with other write leases or read leases because the write operation is not commutative either with other write operations or with read operations: the order in which the operations are executed may affect the result of the operations. To prevent conflicting access to the selected data, no write leases may be issued until all read leases or other write leases on the selected data have been returned or have expired.
Leases may result in latency. For example, there may be significant delays when a number of clients seek conflicting leases for the same selected data. A server can seek to recall a lease when other lease requests are pending, but the server cannot grant other leases until the client returns the lease or the lease expires. In the case of concurrent read leases, the server may have to wait for numerous clients to return their leases before issuing a conflicting write lease. In addition, when a server must respond to lease requests, lease returns, acknowledgement of recall requests, and other messages, processing all these messages alone may overwhelm the server, making it difficult for the server to effectively manage lease requests.